ヘッダーをスキップ
Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド
リリース6.0
B25769-02
  目次へ
目次		 索引へ
索引
前へ
前へ 		次へ
次へ 		 

レプリケーション環境の設定

レプリケーション環境の設定に関連する内容は次のとおりです。

データ・ストアの設定

既存のデータ・ストアの1つ以上の表をレプリケーションできます。レプリケートする必要があるデータ・ストアが存在しない場合は、まず『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータ・ストアの作成に関する章の説明に従って、そのデータ・ストアを作成する必要があります。

マスター・データ・ストアを指定または作成した後、受信マシンでサブスクライバ・データ・ストアのDSN定義を作成します。マスターおよびサブスクライバのデータ・ストアのDSN属性を設定します（次の「データ・ストア属性」を参照）。

サブスクライバのDSNを設定した後、次の2つの方法のいずれかの方法で、マスターからレプリケートする表をサブスクライバ・データ・ストアに移入できます。

データ・ストア属性

レプリケーション・データ・ストアのDSN定義には、次の属性の設定が必要です。

表要件および制限

任意のレプリケーション・スキームでレプリケートする表には、次の特性が必要です。

レプリケーションでは、主キーまたは一意索引を使用して、レプリケート表の各行を一意に識別します。レプリケーションでは、表の索引配列の順次確認で検出された最初の使用可能な索引を常に選択します。主キーがない場合、レプリケーションでは、NULL列が含まれていない最初の一意索引を選択します。また、マスター・データ・ストア内のレプリケート表に対して選択された索引は、サブスクライバ内の対応する表にも存在している必要があります。

注意: レプリケート表のキーは、各更新レコードでサブスクライバに転送されます。キーが小さいほど、より効率的に転送されます。

サブスクライバへのマスター・データ・ストアのコピー

マスター・データ・ストアを完全にレプリケートするサブスクライバ・データ・ストアに内容を移入する簡単な方法は、マスター・データ・ストアの内容をコピーする方法です。また、障害が発生したデータ・ストアのリカバリ時にも、この方法でデータ・ストアをコピーする必要があります（「データ・ストアのフェイルオーバーおよびリカバリの管理」を参照）。

ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データ・ストアを複製できます。ただし、マスター・データ・ストアの内容をコピーしてサブスクライバ・データ・ストアに移入する前に、次の手順を実行する必要があります。

  1. 新しいサブスクライバ・データ・ストアのDSNを作成します。
  2. 「レプリケーション・スキームの定義」の説明に従って、レプリケーション・スキームを作成または変更して、新しいサブスクライバ・データ・ストアおよびそのホストを指定します。
  3. 「データ・ストアへのレプリケーション・スキームの適用」の説明に従って、レプリケーション・スキームをマスター・データ・ストアに適用します。
  4. 「レプリケーション・エージェントの起動および停止」の説明に従って、マスター・データ・ストアのレプリケーション・エージェントを起動します。

    5. たとえば、ホストserver1にはmasterdsデータ・ストアについて記述するmasterDSNという名前のDSNがあり、ホストserver2にはnewstoreデータ・ストアについて記述するnewstoreDSNという名前のDSNがあります。

    newstoreデータ・ストアにmasterdsの内容を移入するには、次の手順を実行します。

server1で:

レプリケーション・スキームを定義し、ttRepStartプロシージャをコールしてレプリケーションを開始するnewrepscheme.sqlという新しいSQLファイルを、テキスト・エディタを使用して作成します。 

CREATE REPLICATION repl.repscheme 
  ELEMENT e TABLE repl.tab 
  MASTER masterds ON "server1" 
  SUBSCRIBER newstore ON "server2"; 
call ttRepStart; 
 

コマンドラインから、レプリケーション・スキームを指定してmasterdsを設定し、レプリケーション・エージェントを起動します。


> ttIsql -f newrepscheme.sql masterds
server2で:

コマンドラインから、masterdsデータ・ストアの内容をnewstoreデータ・ストアにコピーします。 

> ttRepAdmin -dsn newstore -duplicate -from masterds 
-host "server1" 
 

これで、newstoreデータ・ストアにmasterdsデータ・ストアと同じ内容が含まれました。
注意: リモート・ホストの名前またはそのTCP/IPアドレスのいずれかで、-hostを指定できます。TCP/IPアドレスを使用してホストを指定する場合は、-localhostオプションを使用してローカル・ホスト（この例ではserver2）のアドレスを指定する必要があります。詳細は、『Oracle TimesTen In-Memory Database APIおよびSQLリファレンス・ガイド』のユーティリティに関する章のttRepAdminの項を参照してください。

また、ttRepStartプロシージャおよびttRepDuplicateEx C関数を使用して、前述の処理とほぼ同様のコピー処理をCプログラムからも実行できます。詳細は、「レプリケーション・エージェントの起動および停止」および「障害が発生したデータ・ストアのリカバリ」を参照してください。

問題が発生した場合

最新のトラブルシューティング情報については、http://www.oracle.com/technology/documentation/timesten_doc.htmlにある『Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド』のレプリケーションのトラブルシューティングに関する章を参照してください。

レプリケート・データ・ストアのログの管理

この項の内容は次のとおりです。

ログ・バッファのサイズおよび永続性について

TimesTenユーザーに共通に見られる誤解として、ログ・バッファのサイズとトランザクションの消失に関係があるという誤解がありますが、ログ・バッファのサイズは、永続性には影響しません。

DSNがDurableCommits=0で設定されている場合、トランザクションは、次の場合にのみディスクに永続的に書き込まれます。

マスター・データ・ストアでのログの増大について

レプリケーション、XLA、Cache Connectまたは増分バックアップを使用しないデータ・ストアでは、アプリケーションでttCkptまたはttCkptBlockingプロシージャをコールするたびに、ログ・バッファ内の不要なレコードおよび不要なログ・ファイルがパージされます。レプリケート・データ・ストアでは、トランザクションがサブスクライバで完全に処理されたことをマスター・レプリケーション・エージェントが確認するまで、トランザクションはログ・バッファおよびログ・ファイルに保持されます（「レプリケーションの動作」を参照）。マスターは、これを確認した時点でのみ、ログ・バッファおよびログ・ファイルからのパージが必要であると認識します。

サブスクライバの状態が変わると、マスター・データ・ストアのログが、レプリケートされていないデータ・ストアのログより大幅に大きくなる可能性があります（サブスクライバの状態については、「サブスクライバのレプリケーション状態の設定」を参照）。サブスクライバがStart状態の場合、マスターはサブスクライバからの受信確認を受信した後、ログされているデータをパージできます。ただし、サブスクライバが使用不能またはPause状態になると、マスター・データ・ストアのログはフラッシュできず、ログに使用する領域が使い果たされる可能性があります。ログ領域を使い果たすと、マスター・データ・ストアでの後続の更新が強制終了されます。

ログ障害しきい値の設定

しきい値を設定することができます。この値を超えると、使用可能なログ領域を使い果たす前に、使用不可能なサブスクライバをFailed状態に設定します。

ログしきい値を設定するには、CREATE REPLICATIONまたはALTER REPLICATION文でFAILTHRESHOLD値とともにSTOREパラメータを指定します（例1.19を参照）。
注意: ALTER REPLICATIONを使用して既存のレプリケーション・スキームのしきい値を再設定する場合は、まずレプリケーション・エージェントを停止し、ALTER REPLICATIONを使用して新しいしきい値を設定し、そしてレプリケーション・エージェントを再起動します。

デフォルトのしきい値は0（ゼロ）で、「制限なし」を意味します。これ以外のしきい値は、ディスクレス・ロギングを使用しているか、ディスクベース・ロギングを使用しているかによって異なります。詳細は、「ディスクレス・ロギングの属性の設定」および「ディスクベース・ロギングの属性の設定」を参照してください。

マスターは、サブスクライバ・データ・ストアをFailed状態に設定すると、障害が発生したサブスクライバのすべてのデータをログから削除し、そのサブスクライバ・データ・ストアにメッセージを送信します（マスター・レプリケーション・エージェントでサブスクライバ・レプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます）。サブスクライバは、双方向レプリケーションの場合または他のサブスクライバに更新を伝播するように設定されている場合、マスターからメッセージを受信すると、それ以上更新を送信しません。これは、レプリケーションの点からみて自身の状態が損なわれたためです。

障害が発生したサブスクライバに接続中のアプリケーションは、データ・ストアがレプリケーション・ピアによってFailedとマークされたことを示すtt_ErrReplicationInvalid (8025)警告を受信します。サブスクライバ・データ・ストアにその障害状態が通知されると、マスター・データ・ストアでのその状態はFailedからStopに変更されます。

アプリケーションでは、ODBCのSQLGetInfo関数を使用して、接続中のデータ・ストアがFailed状態に設定されているかどうかを確認できます「サブスクライバの障害」を参照）。

ディスクベース・ロギングの属性の設定

最大の利便性と信頼性を得るには、すべてのレプリケーション・データ・ストアに対してディスクベースのロギングを有効（Logging = 1）にします。

ディスクベースのロギングを使用する場合は、データ・ストアをパーマネントとして（Temporary = 0）設定します。一時データ・ストア（Temporary = 1）上で、ディスクベース・ロギング（Logging = 1）は設定できません。

LogBuffSizeでは、インメモリー・ログ・バッファの最大サイズを指定します。このバッファは、一杯になると、ディスク上のログ・ファイルにフラッシュされます。LogBuffSize値を小さくすると、パフォーマンスに影響はありますが、信頼性には影響しません。

ディスクにロギングを行うときの主な問題は、レプリケーション・ログ・ファイルのために十分なディスク領域を確保することです。ログで使用されるディスク領域の量を管理する場合、次の2つ設定があります。

ディスクレス・ロギングの属性の設定

使用可能なディスクがないシステムでTimesTenを実行している場合は、ディスクレス・ロギング（Logging = 2）を使用できます。ただし、次のデメリットを考慮する必要があります。

多数のサブスクライバの設定

レプリケーション・スキームには最大63のサブスクライバを含めることができます。アクティブ・スタンバイ・ペアには、最大62の読取り専用サブスクライバを含めることができます。多数のサブスクライバが含まれるレプリケーション・スキームを計画する場合は、次のことを実行する必要があります。

  前へ
前へ 		次へ
次へ
  目次へ
目次		 索引へ
索引